Agendas: A concept to guide software development activities

We present the concept of an agenda. This concept serves to represent process knowledge in the area of software development. An agenda consists of a list of steps to be performed when developing a software artifact. Each activity may have associated a schematic expression of the language in which the artifact is expressed and some validation conditions that help detect errors. Agendas provide methodological support to their users, make development knowledge explicit and thus comprehensible, and contribute to a standardization of software development activities and products. 1 RE-USE OF DEVELOPMENT KNOWLEDGE Software development comprises a number of development activities, the result of each of which is an artifact, such as a requirements document, a formal specification, program code, and test cases. Experienced software engineers have over time acquired problem-related fine-grained knowledge how to perform the various development activities. To date, such expert knowledge is rarely made explicit. This forces each software engineer to gain experience from scratch. Previously acquired knowledge is not reused to support software processes and not employed to educate novices. Making development knowledge explicit, on the other hand, would support re-use of this knowledge improve and speed up the education of novice software engineers lead to better structured and more comprehensible software processes make the developed artifacts more comprehensible for persons who have not developed them allow for more powerful machine support of development processes. Recently, efforts have been made to support re-use of special kinds of software development knowledge: Design patterns [5] have had much success in object-oriented software construction. They represent frequently used ways to combine classes or associate objects to achieve a certain purpose. Furthermore, in the field of software c IFIP 1996. Published by Chapman & Hall 2 Agendas – A Concept to Guide Software Development Activities architecture [16], architectural styles have been defined that capture frequently used design principles for software systems. This work presents the concept of an agenda. An agenda gives guidance on how to perform a specific software development activity. Whereas concrete agendas are very much oriented on the activity to be supported, the general concept of an agenda is not specialized to a programming paradigm such as object-orientedness or an activity such as software design, as is the case for design patterns and architectural styles. Agendas can be used for structuring quite different activities and in different contexts. We have set up and used agendas that support requirements engineering, specification acquisition, software design using architectural styles, object-oriented analysis and design, and developing code from specifications [8]. Agendas are especially suitable to support the application of formal techniques in software engineering. Formal techniques have the advantage that one can positively guarantee that the product of a development step enjoys certain semantic properties. In this respect, formal techniques can lead to an improvement in software quality that cannot be achieved by traditional techniques alone. Moreover, when the semantics of the developed artifact is taken into account, stronger machine support, e.g., by theorem provers, becomes possible. A major drawback of formal techniques, however, is that they are not easy to apply. Users of formal techniques need an appropriate education. They have to deal with lots of details, and often they are left alone with a mere formalism without any guidance on how to use it. For the application of formal techniques in software engineering, the means for mastering complexity and for finding common patterns in different products and different processes are at least as important as in classical software engineering. Agendas tackle these problems. In the following, we introduce the concept of an agenda in more detail and give examples of concrete agendas (Section 2). Then we discuss the distinguishing features of agendas in Section 3. Related work is discussed in Section 4, and a summary of what has been achieved concludes the paper (Section 5).